home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Tools (InfoMagic)
/
Internet Tools.iso
/
dos_win
/
winsock
/
maillist
/
94-05.Z
/
94-05
/
000208_news@bigblue.oit.unc.edu_Sun May 15 22:44:24 1994.msg
< prev
next >
Wrap
Internet Message Format
|
1994-05-31
|
11KB
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA18578; Sun, 15 May 1994 18:15:14 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA34008; Sun, 15 May 1994 17:44:36 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Sun, 15 May 1994 22:44:24 GMT
From: leyx0006@gold.tc.umn.edu (Bob Zimbinski)
Message-Id: <leyx0006.3.00135767@gold.tc.umn.edu>
Organization: University of Minnesota, Twin Cities
Sender: ses
References: <leyx0006.2.0043D43D@gold.tc.umn.edu>, <patlee.506.0012F66D@panix.com>
Subject: Re: Stabilizing Win Mosaic 2b4
In article <patlee.506.0012F66D@panix.com> patlee@panix.com (Patrick Lee) writes:
>From: patlee@panix.com (Patrick Lee)
>Subject: Re: Stabilizing Win Mosaic 2b4
>Date: Sun, 15 May 1994 08:38:58 EDT
>In article <leyx0006.2.0043D43D@gold.tc.umn.edu> leyx0006@gold.tc.umn.edu (Bob Zimbinski) writes:
>Make sure you are running it on a 486 with 8 MB of RAM and a good nice swap
>file ... There's also seems to be problem with Mosaic not returning resources
>back to Windows after it exits.
I'm running a 486/33 with 16 MB of RAM and a huge stinking swap file. I've
tried it with no other applications running and I've gone over the .ini file
several times. This is frustrating...
Bob Zimbinski
leyx0006@gold.tc.umn.edu
From news@bigblue.oit.unc.edu Sun May 15 18:45:13 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA22643; Sun, 15 May 1994 18:45:13 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA35336; Sun, 15 May 1994 18:34:35 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: Sun, 15 May 1994 17:20:02
From: tnert@utxsvs.cc.utexas.edu (Trent Stevens)
Message-Id: <tnert.735.00115602@utxsvs.cc.utexas.edu>
Organization: UT Austin
Sender: ses
References: <tnert.734.000FF6E9@utxsvs.cc.utexas.edu>
Subject: Re: IVC Users--CALL ME! (Apologies to Deborah Harry)
In article <tnert.734.000FF6E9@utxsvs.cc.utexas.edu> tnert@utxsvs.cc.utexas.edu (Trent Stevens) writes:
>From: tnert@utxsvs.cc.utexas.edu (Trent Stevens)
>Subject: IVC Users--CALL ME! (Apologies to Deborah Harry)
>Date: Sun, 15 May 1994 15:57:45
>OK, now that I've gotten your attention: has anyone gotten IVC to work yet?
>If so, please give me a call at 128.83.204.17 (the SLIP address will only be
>good until 7PM EDT). I'm using Chameleon, so there shouldn't be any major
>problems on this end.
Sorry for the clichi, but I have to say: NOT! Windows apparently was running
low on resources, so I had to reboot (after two IVC GPFs). I'm up again for
the moment, so if you'd like to try (again?), the number is 128.83.128.80.
Thanks again for your help and your patience!
Trent Stevens tnert@bisque.cc.utexas.edu
From news@bigblue.oit.unc.edu Tue May 13 19:59:38 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA22650; Sun, 15 May 1994 18:45:15 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA23506; Sun, 15 May 1994 18:28:30 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: 13 May 1994 19:59:38 GMT
From: poffen@San-Jose.ate.slb.com (Russ Poffenberger)
Message-Id: <2r0m7a$lf1@k2.San-Jose.ate.slb.com>
Organization: Schlumberger Technologies, ATE division, San Jose, Ca.
Sender: ses
References: <1994Apr22.161426.145506@ans.net>, <matt.10.2DCAB5B1@sc1.tamu.edu>, <CpqvDB.MpC@cyanamid.uucp>
Subject: Re: 32 bit access with SCSI no available. Hunh? was Re: Win Mosaic alpha 4 (my fix)
Vic Kamhi (kamhiv@pt.cyanamid.com) wrote:
: In article <trumpet-support.171.2DD2E384@petros.psychol.utas.edu.au>,
: >
: > My questions are...
: >
: > Can you buy comparable large hard disks for IDE controllers?
: > At the same price?
: > Are the driver problems we are experiencing ever going to be resolved?
: >
: > Peter
: >
: Apparently Enhanced IDE drives are on their way. The claims are:
: 1) bigger drives supported without kludges
: 2) more drives supported (4 instead of 2)
: 3) non-disk devices (i.e., CD-ROMS) supported
: 4) faster (near SCSI) speeds
: Reports in the trade press (take that for what it's worth!) say that you
: should be seeing the Enhanced IDE stuff by this fall in many high-end
: (i.e., 486DX3 and Pentium) systems. They say that Phillips (?) will be
: introducing an IDE CD-ROM almost as you read this.
: Except that SCSI still can support more devices per chain (but many don't
: need 6!), more types of devices (scanners, tape drives; but, again, not
: everybody needs these), and will still be inherantly faster (except, of
: course, for the proviso about 32-bit under Windows), this new IDE system
: might be just what the doctor ordered for many!
: --VIC
It still lacks the multitasking features that SCSI has. Under a true multi-
tasking OS like UNIX, OS/2 or NT, SCSI can make a big difference.
Russ Poffenberger DOMAIN: poffen@San-Jose.ate.slb.com
Schlumberger Technologies ATE UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive CIS: 72401,276
San Jose, Ca. 95110 Voice: (408)437-5254 FAX: (408)437-5246
From news@bigblue.oit.unc.edu Tue May 13 19:54:40 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA22657; Sun, 15 May 1994 18:45:16 -0400
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
id AA23505; Sun, 15 May 1994 18:28:29 -0400
Received: from GATEWAY by bigblue with netnews
for winsock@sunsite.unc.edu (winsock@sunsite.unc.edu)
To: winsock@sunsite.unc.edu
Date: 13 May 1994 19:54:40 GMT
From: poffen@San-Jose.ate.slb.com (Russ Poffenberger)
Message-Id: <2r0lu0$lf1@k2.San-Jose.ate.slb.com>
Organization: Schlumberger Technologies, ATE division, San Jose, Ca.
Sender: ses
References: <CppIL6.vK@nntpa.cb.att.com>, <2quet0$8u3@bmerha64.bnr.ca>, <arnsteinCpr4MC.HL5@netcom.com>
Subject: Re: 32 bit access with SCSI not avail. -> Adaptec questions.
David Arnstein (arnstein@netcom.com) wrote:
: In article <2quet0$8u3@bmerha64.bnr.ca>, Jeff Hayes <jjhayes@bnr.ca> wrote:
: >
: >_]What you desperately need is an ASPI driver that either (a) supports
: >_]the virtual DMA interface directly, or (b) provides the necessary
: >_]buffering itself. This will allow you to get rid of the SMARTDRV
: >_]/DOUBLE_BUFFER line in your CONFIG.SYS.
: > Adaptec docs say to remove the /DOUBLE_BUFFER, set VirtualHDIRQ=off
: >in system.ini to make everything happy in Windows.
: >
: >_]Adaptec's ASPI4DOS has a switch to provide the necessary
: >_]buffering itself
: > I have the Adaptec docs here in front of me and there is no
: >switch to enable buffering in aspi4dos. Neither do any of the other 3
: >drivers. Hummm.
: >
: > So...
: >
: > The questions to answer (Adaptec's docs do not) are:
: >
: > Do the Adaptec drivers support VDMA?
: > Do they do there own buffering?
: > Is there buffering cache on the ctlr board?
: Just listen to all this complexity! If you have the guts, do a
: quantitative comparison of speed of your SCSI nightmare with an IDE
: drive - while running Windows 3.1. Have you gained any speed?
Load an ASPI driver and compare. Probably little difference. Now try comparing
a SCSI based system with multiple devices (disks, tapes, CDROM) on a true
multitasking OS like NT or OS/2 against an IDE drive, and see which one is
faster.
Russ Poffenberger DOMAIN: poffen@San-Jose.ate.slb.com
Schlumberger Technologies ATE UUCP: {uunet,decwrl,amdahl}!sjsca4!poffen
1601 Technology Drive CIS: 72401,276
San Jose, Ca. 95110 Voice: (408)437-5254 FAX: (408)437-5246
From rcq@mailserv-D.ftp.com Sun May 15 15:30:47 1994
Received: from ftp.com (wd40.ftp.com) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
id AA28974; Sun, 15 May 1994 19:32:11 -0400
Received: from ftp.com by ftp.com ; Sun, 15 May 1994 19:32:10 -0400
Received: from mailserv-D.ftp.com by ftp.com ; Sun, 15 May 1994 19:32:10 -0400
Received: from rcq.sidearm.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4)
id AA13016; Sun, 15 May 94 19:30:47 EDT
Date: Sun, 15 May 94 19:30:47 EDT
Message-Id: <9405152330.AA13016@mailserv-D.ftp.com>
To: emw@netcom.com
Subject: Re: questions re closesocket(), shutdown(), etc
From: rcq@ftp.com (Bob Quinn)
Reply-To: rcq@ftp.com
Cc: Multiple recipients of list <winsock@sunsite.unc.edu>
Sender: rcq@mailserv-D.ftp.com
Repository: mailserv-D.ftp.com, [message accepted at Sun May 15 19:30:41 1994]
Originating-Client: sidearm.ftp.com
Content-Length: 1828
> When talking to the other side and you receive an error saying the
> connection was reset by peer, do you still need to shutdown and/or close
> the socket? How about if the connection is closed by the other side? I've
> read the spec and can't find anything definitive. Is it stack dependent?
After a TCP socket receives a reset--at initial connection attempt
or while connection is active--you still need to call closesocket().
You always need to call closesocket(). This function "releases the
socket descriptor", and any associated resources (e.g. memory allo-
cated for WinSock internal socket structures). This requirement is
*not* implementation dependent (i.e. it's universal).
You need not call shutdown() after receiving a reset, though
it shouldn't cause a problem to do so. It may fail with the
WSAENOTCONN error, though this *is* implementation dependent.
It might not fail, or it might return a different error. Even
though they're not listed for shutdown(), it would be legal for a
WinSock to report either WSAECONNABORTED or WSAECONNRESET errors
after such a failure from shutdown() (see section 3.3.4 Error
Handling on page 16, for the caveat in the last paragraph).
After the other side initiates the graceful close of a connection,
you need to call closesocket() (or shutdown()) to complete the
close. Unlike when your side initiates the close, in this case
calling shutdown() before closesocket() should not be necessary.
Because the other side already sent a <FIN>, you know they won't
be sending any more data, and the main reason to call shutdown()
(with "how=1") before closesocket() is to read any remaining data
before releasing the socket.
Regards,
--
Bob Quinn rcq@ftp.com
FTP Software, Inc. No. Andover, MA